AWSでの脆弱性対策の考え方と対策ソリューション

はじめに

AWSの運用構築を任されたかたに向けて、OS/ミドルウェア/アプリケーションにおける脆弱性対策の基本的な考え方と対策ソリューションをご紹介します。

脆弱性とは

脆弱性とはアプリケーションやOSなどの不具合などによって発生するセキュリティ上の欠陥です。
悪意のある攻撃者が脆弱性を利用した攻撃を行うと、アプリケーションやOSが意図しない動作をする事で情報が流出したり、悪意のあるマルウェアに感染するといった恐れがあります。
多くの開発者が安全なウェブサイトの作り方やOWASP Top 10などを参考にするなど脆弱性の少ないソフトウェア開発に努めていますが、脆弱性が全くないソフトウェアは現実的ではありません。
セキュリティインシデントの中で、脆弱性をついた攻撃は最も多い原因の1つです。
システムを安全に維持運用していくためには、脆弱性と上手に付き合っていく事が大切です。

脆弱性対策を行わないリスク

Webサーバーやアプリケーションを公開すると、悪意のあるユーザーからの攻撃を受けます。
攻撃の対象は組織やユーザー数の大小に関係ありません。個人で運営するような小規模なサイトも対象になります。

攻撃を受けてしまった場合、"被害者"になると同時に"加害者"になる可能性がある点に考慮が必要です。
攻撃の内容によっては、スパムメールを送信したり、悪意のあるマルウェアを配布するサーバーに改ざん（ドライブバイダウンロード攻撃）されてしまいます。
改ざんによって迷惑行為を行う事で社会的信用を失ったり、訴訟を受ける可能性があります。
AWSではこのような迷惑行為は禁止されておりAWSからの連絡を放置した場合、インスタンスやアカウントを停止されるといった可能性もあります。
「小規模なサイトだから」「機密情報を扱っていないから」などは脆弱性対策を行わない理由になりません。

基本的な対応はソフトウェアアップデート

脆弱性が発見されると多くのソフトウェアベンダーは、脆弱性が修正されたバージョンをリリースします。
脆弱性対策の最も重要な対応はソフトウェアアップデートです。

CVE-IDによる脆弱性の識別と情報収集

CVE(Common Vulnerabilities and Exposures)は、非営利団体のMITRE社が採番している識別子です。
脆弱性に識別番号（CVE-ID）を採番することで、主に相互参照や関連付けに利用されます。
OSやミドルウェアの脆弱性対応を行う場合はCVE-IDを確認し対応します。

Amazon Linuxの場合、Amazon Linux AMI Security CenterでCVE-IDを確認できます。
重要度や注目度の高い脆弱性はAWSからアナウンスされたり、組織内周知される事があります。
Twitterなどのソーシャルネットワーキングサービスも有効な情報収集手段です。

責任共有モデルで考える役割分担

AWSのセキュリティはAWSと利用者が協力して達成します。
責任共有モデルはAWSと利用者の担当範囲を示します。
Amazon EC2の場合、主にOS自体やミドルウェア、アプリケーションなどOS以上のレイヤーはユーザーが担当し、物理サーバーやデータセンターなどはAWSが担当します。
ユーザはOS、ミドルウェア、アプリケーションの脆弱性対策を行う必要があります。

ソフトウェアアップデートには、大きく課題が2つあります。
1つ目にアプリケーションが動作しなくなる可能性があります。
アプリケーションが特定のライブラリバージョンに依存しているようなケースです。
事前に検証を行い、動作確認を行います。
2つ目にOSやサービスの再起動が必要な事が多いです。
サービスを利用できない時間が発生する可能性があります。
アップデートの作業負担を減らすために以下の2点を検討します。

マネージドサービスの検討

マネージドサービスを利用する事で、脆弱性対策の負担を減らす事ができます。
Amazon RDSとAmazon S3を例に紹介します。

RDSはリレーショナルデータベースサービスです。
OSやDBエンジンのアップデートについて、RDSの機能を使う事で簡単に行えます。
DB関連のアップデートは障害発生時の影響が大きい場合があり、怖くて中々できないケースも多いのではないでしょうか。
RDSは簡単にアップデート出来る事によって、セキュアな状態を保ちやすいメリットがあります。

S3はオンラインストレージのWebサービスです。
OSやアプリケーションのアップデートについてAWSが担当するため、ユーザー側で意識する事はありません。

アップデートしやすいアーキテクチャの検討

事前検証とアップデート方法の2点を検討し、アップデートしやすいアーキテクチャを採用しましょう。

事前検証

AMIコピーによるアップデート検証
本番環境と同等の環境がある場合、アップデートと動作検証を行います。
コストの問題で検証環境を常に用意する事が難しい場合、インスタンスのAMIを取得し検証用のインスタンスを作成します。
作成したインスタンスをアップデートし、アプリケーションの動作確認を行います。
複数実行されると困るバッチやジョブがある場合、注意してください。
具体的には、セキュリティグループなどによって隔離しcronやエージェントを停止します。

アップデート方法

代表的なアップデート方法をご紹介します。

EC2単体のIn place方式
対象のインスタンスをそのままアップデートする方式です。
事前にAMIを取得したり、後述のメンテナンスページを用意しておくといいでしょう。

DNSによるBlue/Green方式
新しい環境(Green)を用意しアップデートを行います。元々の環境（Blue）は変更しません。
DNSレコードを変更してGreenに切り替えます。
Green環境に問題が発生した場合は、DNSレコードを切り戻します。

ELBを使ったOne by one方式
ELB配下に複数のインスタンスが登録されている場合、1台ずつ登録解除しアップデートする形がとれます。
インスタンスの数だけ登録解除/アップデート/登録を繰り返します。

メンテナンスページの構築
Webサービスの場合メンテナンスページを用意し、アップデート作業中はメンテナンスページに誘導できます。
Amazon CloudFrontとAmazon S3を利用すると、HTTP 503を返すメンテナンスページを作成できます。
静的なファイル（htmlファイルなど）をS3に配置しておく事で、「メンテナンス実施中です」等のメッセージを表示します。

参考： CloudFrontのCustom Error Responseを利用して、S3上にあるSorryページを表示する

脆弱性をついた攻撃の3ステップ

攻撃の手法は様々ですが、「脆弱性を利用した攻撃」「攻撃の準備」「不正プログラムの設置」の3ステップで説明します。

脆弱性を利用した攻撃

悪意のある攻撃者はソフトウェアの脆弱性を利用して、攻撃の準備を行います。

攻撃の準備

攻撃を拡大するためにユーザーを作成したり設定ファイルを変更するといった改ざんを行います。

不正プログラムの設置

不正プログラムを設置して、外部に情報を持ち出したり迷惑行為を行います。

3ステップにおける対策

攻撃の3ステップにおける対策をご紹介します。
IPS/セキュリティログ監視/変更監視/アンチウイルス/Webレピュテーション/アプリケーションコントロールの例として、Trend Micro Deep Securityを挙げます。
アンチウイルスの例としては、SophosとF-Secureを挙げます。

脆弱性の修正

バージョンアップ/パッチ適用

脆弱性の修正の根本的な対応は、ソフトウェアのバージョンアップまたはパッチ適用です。
ソフトウェアのバージョン管理にSystems Manager インベントリとAWS Configを役立てられます。
Systems Manager インベントリを利用すると、AWSコンソールからEC2にインストールされたアプリケーション情報を確認できます。
Systems Manager インベントリとAWS Configを組み合わせると、ソフトウェアのアップデート履歴を記録/追跡できます。

公式ページ: AWS Systems Manager、AWS Config

脆弱性診断

脆弱性診断を行い脆弱性のあるソフトウェアを利用していないか確認します。
脆弱性のあるOS、ミドルウェア、アプリケーションは外部からの攻撃が成立しやすいです。
アプリケーション公開前に診断と修正を行い、公開後も定期的に診断とアップデートを行います。

Amazon Inspector

EC2にエージェントをインストールし、脆弱性が含まれるか確認します。
Webアプリケーションの診断は診断対象外です。

公式ページ: Amazon Inspector

フートスキャン

F-Secure RADARを利用した脆弱性スキャンサービスです。
ツールによるスキャンのため、安価に利用できる点が特徴です。
外部からシステムにアクセスし、アプリケーション、OS、ミドルウェアに脆弱性がないか確認します。

公式ページ: フートシリーズ（運用保守）

防御

セキュリティグループ

セキュリティグループはファイアウォール"に相当する機能です。
セキュリティグループを適切に設定しておけば、不必要な通信をEC2に到達する前に遮断できます。
必要なポートと送信元のみ許可するようにします。
LinuxのWebサーバーの場合、SSHとHTTP(S)のみ許可します。
利用者が特定出来る場合、オフィスなどの特定IPのみ許可します。

IPS

OSやミドルウェアの脆弱性をついた攻撃を遮断します。
IPSによる防御はパッチ適用までの時間稼ぎと考えます。
また、誤って正しい通信を遮断してしまう恐れがあるため新しいルールは検知のみ行い、様子を見てから遮断に切り替えます。

参考：侵入防御の設定

WAF

Webアプリケーションの保護にWAFを利用できます。
AWSでWAFを導入する理由と最適な選択をあわせてご覧ください。

AWS WAF
マネージドなWAFサービスです。
SQLインジェクションやクロスサイトスクリプティング（XSS）等のWebアプリケーションに対する攻撃に対応できます。
ルールを自由に定義できるほか、パートナーが提供するマネージドルールを利用できます。

公式ページ: AWS WAF – Web アプリケーションファイアウォール

Imperva Incapsula
Impervaが提供するクラウド型WAFです。
bot検知と動的な攻撃学習機能によってWebアプリケーションへの自動攻撃を検知し、セキュリティリスクを防ぎます。

公式ページ： Imperva Incapsula

アンチウイルス

AWS Security Best Practicesでは、マルウェア対策としてアンチウイルス/アンチスパムソフトウェアがあげられています。
不正プログラムを駆除しインスタンスを守ります。

Webレピュテーション

Webレピュテーションは不正なURLへの通信をブロックします。

参考：Webレピュテーションのセットアップ

アプリケーションコントロール

アプリケーションコントロールは、アプリケーションの変更を管理する機能です。
ソフトウェアの許可ルールを作成しておくことで、ゼロデイのランサムソフトウェア等に対応出来ます。

参考：アプリケーションコントロールの有効化

検知

システムへの攻撃は目立たないように行われる事が多いです。
攻撃の予兆や攻撃が成立してしまった事に早く気がつく事が重要です。

Amazon GuardDuty

AWS内の不審なアクティビティを検知するセキュリティモニタリングサービスです。
VPCフローログ、DNSログを監視し、不審な通信が行われか確認します。
EC2がマルウェアに感染した際の不審なアクティビティに気がつく事ができます。

公式ページ:Amazon GuardDuty

セキュリティログ監視

OSやミドルウェアのログを監視し、不審なアクティビティが行われていないか確認します。

参考：セキュリティログ監視の設定

変更監視

OSやミドルウェアの重要なファイルを監視し、ファイルの内容やパーミッションなどが変更されていないか確認します。
ベースラインを作成し変更をベースラインと照合します。
アップデートや設定変更などを行なった場合ベースラインを更新します。

参考：変更監視の設定

おわりに

AWSの運用構築を任されたかたに向けて、OS/ミドルウェア/アプリケーションにおける脆弱性対策の基本的な考え方と対策ソリューションをご紹介しました。
セキュリティインシデントの中で、脆弱性をついた攻撃は最も多い原因の1つです。
脆弱性対策の根本的な対策はソフトウェアのバージョンアップですが、事前検証や再起動などの課題があります。
マネージサービスを採用したり、アップデートを工夫する事で柔軟にアップデート出来るように準備しましょう。
脆弱性にすぐに対応出来る事は少ないため、ご紹介したWAFやIPSについてもご検討ください。